Skip to content

chore(openapi): update OpenAPI client to 2026.05.05.1506-da651a2#584

Merged
LinoGiger merged 2 commits into
mainfrom
chore(openapi)/update-openapi-client-with-classify-fix
May 6, 2026
Merged

chore(openapi): update OpenAPI client to 2026.05.05.1506-da651a2#584
LinoGiger merged 2 commits into
mainfrom
chore(openapi)/update-openapi-client-with-classify-fix

Conversation

@RapidPoseidon

@RapidPoseidon RapidPoseidon commented May 6, 2026

Copy link
Copy Markdown
Contributor

Summary

Reopens #581 on a fresh branch with the type-check failure fixed.

The OpenAPI generator renamed the inline category model on IRapidBlueprintAttachCategoryRapidBlueprint.categories from Category to AttachCategoryRapidBlueprintCategory, but ClassifyWorkflow._to_model was still constructing Category(...) instances — pyright caught the mismatch.

Changes

  • Cherry-picked the original generator commit (a18e35a) untouched: 95 files, +2416 / -758, the schema bump to 2026.05.05.1506-da651a2.
  • fix(workflow): in src/rapidata/rapidata_client/workflow/_classify_workflow.py, swap CategoryAttachCategoryRapidBlueprintCategory (same shape: label: str, value: str).

Test plan

  • pyright (v1.1.396, CI version) passes from src/rapidata/rapidata_client0 errors, 0 warnings, 0 informations
  • Wait for CI type-check to go green on this PR
  • Close #581 once this merges

🔗 Session: session-b375f1aa

Rudolf the Rabbit and others added 2 commits May 6, 2026 08:23
Co-Authored-By: lino <lino@rapidata.ai>
…assifyWorkflow

Co-Authored-By: lino <lino@rapidata.ai>
@claude

claude Bot commented May 6, 2026

Copy link
Copy Markdown

Code Review — PR #584: OpenAPI client update to 2026.05.05.1506-da651a2

Overview

This PR is a clean reopen of #581, cherry-picking the generator commit (a18e35a) and adding a targeted fix in _classify_workflow.py. The bulk of changes (+2416 / -758) is auto-generated OpenAPI client code; the only hand-written change is the CategoryAttachCategoryRapidBlueprintCategory swap. Pyright passes cleanly.


✅ What looks good

The workflow fix is correct.
_classify_workflow.py:63-67 — Swapping Category(label=option, value=option)AttachCategoryRapidBlueprintCategory(label=option, value=option) is exactly right. Both models have identical shapes (label: str, value: str), so there's no behavioural change, only the type annotation is now accurate.

Schema nullability is now explicit.
Dozens of fields (file sizes, bounding-box coordinates, audience scores, boost thresholds, etc.) now carry nullable: true. This is a correctness improvement — previously the generator would emit Optional[...] only by convention; now it's schema-driven.

New IAudienceFilterDemographicAudienceFilter is cleanly added to the discriminated union with a proper _t discriminator, consistent with the existing filter hierarchy.

New minResponsesToGraduate field has a clear description and the right nullable: true annotation for an optional threshold.


⚠️ Points to note / potential issues

1. Breaking changes in auto-generated types (low SDK risk, but worth flagging)

Three type renames propagate into the public API surface of api_client:

Old name New name
PagedResultOfQueryJobsResult QueryAudienceJobsEndpointPagedResultOfOutput
QueryJobsResult QueryAudienceJobsEndpointOutput
AudienceJobState AudienceJobStatus (in audience.openapi.json)

audience_api.py return type for audience_audience_id_jobs_get changes accordingly. Any downstream code that imported these types by name from rapidata.api_client.models will get an ImportError. This is expected for an auto-generated layer, but worth calling out in release notes if the SDK has external consumers who reach into api_client.

2. AudienceJobState is partially retained — possible confusion

In rapidata.filtered.openapi.json and rapidata.openapi.json, AudienceJobState is re-added in the diff alongside the new AudienceJobStatus. This looks intentional (both schemas exist in the aggregated spec because different endpoints still reference the old enum in those contexts), but it means AudienceJobState will still be generated as a Python class. Worth verifying there's no accidental duplication or two classes with different values.

3. Category Python file not deleted?

The diff removes the Category import from both i_rapid_blueprint_attach_category_rapid_blueprint.py and _classify_workflow.py, but there's no diff --git entry deleting src/rapidata/api_client/models/category.py. If that file still exists on disk (orphaned by the generator), it's harmless but untidy. Worth a quick git status/ls sanity check post-merge.

4. CLAUDE.md: mustache templates

Per project convention, changes to auto-generated files must be reflected in the mustache templates under openapi/templates/. This PR doesn't touch those templates. If the nullable-field serialization pattern (e.g. the to_dict guard blocks added in boosting_profile_model.py, bounding_box_result_model_box.py, etc.) comes from a template, the templates should already cover it. If you confirm the template already generates those blocks, this is a non-issue.


Minor observations

  • The updated api_client_README.md fills in previously-blank endpoint descriptions (e.g. campaign_boost_preheat_post, orders_get). Good.
  • The new AudienceJobStatus enum has MANUALAPPROVAL = 'ManualApproval' — no word separator. This is consistent with the existing generator output style (SUBMITTED, RUNNING, etc.).

Summary

The fix is correct, minimal, and type-safe. The rest is mechanical generator output. Main thing to double-check before merge:

  1. Confirm category.py is genuinely gone (or intentionally kept for another use).
  2. Verify the AudienceJobState / AudienceJobStatus dual presence is intentional in the aggregated schemas.
  3. Note the API-client-level type renames in the changelog/release notes if the api_client layer is considered part of the public API.

Otherwise this looks good to merge. 🟢

@LinoGiger LinoGiger merged commit d9e5f31 into main May 6, 2026
2 checks passed
@LinoGiger LinoGiger deleted the chore(openapi)/update-openapi-client-with-classify-fix branch May 6, 2026 14:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants